Testautomatisierung am Beispiel des COBOL-to-Java-Converters CoJaC

Im Rahmen von Migrationsprojekten steht immer die Frage, ob sich das migrierte System semantisch äquivalent zum Ausgangssystem verhält. Dabei liegen die Fehlerquellen nicht nur in den migrierten Programmen, sondern auch in deren Laufzeitumgebung. Der folgende Beitrag zeigt die Integration von automatisch erstellten Unittests am Beispiel der Migration von COBOL nach Java mit CoJaC. Das Ziel ist die Aufwandreduktion des Tests der migrierten Programme und der Laufzeitumgebung. 1 Migration mit CoJaC Mit dem COBOL-to-Java-Converter CoJaC1 stellte pro et con einen Translator für die Migration von COBOL nach Java vor. Das Werkzeug migriert Quelltext aus COBOL in äquivalentes Java. Dabei erfolgt die Abbildung eines COBOL-Programms auf eine Java-Klasse. Zum Ablauf der Java-Programme wird das Laufzeitsystem CoJaC-RTS benötigt. Das dient dazu, spezielle Eigenschaften der Sprache COBOL (z. B. Typsystem und Systemfunktionen) in Java zu emulieren. Die im Ergebnis der Konvertierung entstehenden Java-Programme müssen nach der Migration auf semantische Äquivalenz zum Original getestet werden. Das Ziel war es, die Tests der migirerten Java-Programme, als auch des CoJaC-RTS zu automatisieren. Die dazu entwickelte Technologie basiert auf einem bereits vorgestellten Testverfahren2. 2 Test durch Vergleich von Ausgaben Die erste Ausbaustufe des automatisierten Testverfahrens besteht in einem textbasierten Vergleich der Ausgaben des originalen COBOL-Programmes und der konvertierten Java-Kopie. Dabei wird die Eigenschaft von COBOL genutzt, Variablen und Strukturen zu einer Zeichenkette serialisiert auszugeben. Dazu wird der COBOL-Befehl DISPLAY genutzt. Da dieser Befehl auch in die JavaLaufzeitumgebung CoJaC-RTS integriert wurde, besteht die Möglichkeit, die Ausgaben beider Programmwelten miteinander zu vergleichen. Damit ein solches Testverfahren funktioniert, muss natürlich gewährleistet sein, dass das COBOL-Programm aussagekräftige Ausgaben erzeugt. Ist das nicht der Fall, müssen diese noch in einem vorbereitenden Schritt in das Programm integriert werden. Das Verfahren besteht auf der Grundannahme, dass ein Befehl semantisch äquivalent ist, wenn er zu identischen Eingabedaten identische Ergebnisse liefert. Diese Annahme lässt sich auch auf vollständige Programme als Folge von Anweisungen übertragen. Das Testverfahren wird in der folgenden Abbildung dokumentiert: Zunächst werden die COBOL-Programme mit CoJaC konvertiert (1). Anschließend werden die Programme in beiden Systemwelten ausgeführt (2), damit die Ausgaben der Programme entstehen. Der letzte Schritt besteht im Vergleich der erstellten Daten (3). Trotz der Reduktion des Aufwandes gegenüber dem Test durch Debugging ist der manuelle Anteil insbesondere bei komplexen Programmen immer noch hoch. Dieser liegt vor allem im Vergleich der erzeugten Ausgabedaten und in der manuellen Bewertung der gefundenen Unterschiede. 3 Testtreiber und JUnit Eine weitere Reduzierung des Testaufwandes war zu erwarten, wenn die Vergleichsmöglichkeiten und Testbewertungen zumindest teilautomatisiert erfolgen. Zunächst wurden dazu in einer Analyse des Quelltextes Methoden ermittelt, welche als Einstiegspunkte in die Verarbeitung dienen. Diese sollten in Folge genutzt werden, um die entsprechenden Teilprogramme/Teilsysteme zu testen. Dazu wurde in die konvertierten Java-Quellen eingegriffen und jede entsprechende Methode mit einem so genannten Testtreiber instrumentiert. Dieser erhält die Eingabedaten für den Test in einer standardisierten Form, ruft das eigentliche Java-Programm auf und vergleicht die Rückgabe mit einem Erwartungswert. Damit auch die kommerziell häufig vorkommenden komplexen COBOL-Strukturen für die Einund Ausgabedaten behandelt werden können, wurde an dieser Stelle erneut auf die Möglichkeiten der Serialisierung von Zeichenketten durch das Laufzeitsystem zurückgegriffen. Die notwendigen Daten für dieses Testverfahren wurden mit Hilfe des bestehenden COBOL-Systems ermittelt. Analog zur Stufe 1 wurden die Eingabeund Ausgabedaten erstellt und in geeigneter Form im Testtreiber hinterlegt. Da dieses Verfahren mit festen Erwartungswerten arbeitet, war es möglich, die Testtreiber als Unittests zu realisieren. Dazu wurde das in Java übliche JUnit eingesetzt. Dadurch stieg zwar die Geschwindigkeit für die Bewertung, ob ein (Teil-)System korrekt arbeitet. Allerdings ist bei diesem Verfahren der manuelle Aufwand zur Implementierung von Testtreibern der wesentliche Anteil am Testaufwand. 4 Generierte JUnit Tests Die finale Version des Testverfahrens sollte beide Wege kombinieren. Die schnelle Bewertbarkeit durch JUnit sollte mit der einfachen Testmethode des textuellen Vergleichs verbunden werden. Die Lösung für diese Anforderung sind Unittests, welche die Ausgaben des COBOL-Programms aus Stufe 1 nutzen, um daraus automatisiert JUnit-Testfälle zu generieren. Die folgende Abbildung zeigt das Verfahren. Für die Umsetzung dieser Variante müssen die Ausgaben maschinell auswertbar sein. Dazu werden die bestehenden Meldungen standardisiert und erweitert. Darüber hinaus muss es möglich sein, die Ausgaben der COBOLProgramme mit den generierten Java-Programmen zu verknüpfen. Dazu wurden die bestehenden Ausgaben um die Präfixe/Tags #CASE# (normale Testausgaben) und #METHOD# (Methodenzuordnung) erweitert. Das folgende Beispiel zeigt Ausschnitte aus dem angepassten COBOL-Programm 01 PROCEDURE DIVISION. 02 DISPLAY "#METHOD#PROCEDURE" 03 MOVE SOME-TEXT TO SOME-NUMBER 04 DISPLAY "#CASE#", SOME-NUMBER Im Beispiel wird im Hauptparagraphen des Programms eine Zeichenkette (SOME-TEXT) einer numerischen Variablen (SOME-NUMBER) zugewiesen. Mittels des DISPLAYs auf Zeile 02 werden die darauf folgenden Ausgaben dem Hauptparagraphen zugeordnet. Das DISPLAY auf Zeile 04 dient dem Test des MOVE-Statements auf Zeile 03. Dieses Programm liefert nach Ablauf folgende Ausgaben: 01 #METHOD#PROCEDURE